This invention relates to computer systems for automobile vehicles. More particularly, this invention relates to software for such computer systems. More particularly still, this invention relates to software programming interfaces for such computer systems.
Modern automobile vehicles are typically equipped with several independent electronic systems. For example, many vehicles have the following systems: sound systems, security systems, vehicle diagnostic systems, global positioning system (GPS) navigational systems, and wireless communications systems.
Most late model automobiles are constructed with a diagnostic system that analyzes performance of the vehicle""s engine, transmission and fuel system, and other vehicle peripheral devices. In particular, 1993-1995 model vehicles use a standard called OBD I, and 1996 model vehicles or later have OBD II. (OBD is On-Board Diagnostics).
The various vehicle electronics systems have proven useful to their users. However, these systems are typically unrelated and incompatible. This problem was solved by in-vehicle computers. A popular example of such an in-vehicle computer (xe2x80x9cvehicle computerxe2x80x9d) is a product known as xe2x80x9cAuto PCxe2x80x9d and its associated operating system. A vehicle computer, like the xe2x80x9cAuto PC,xe2x80x9d is described in detail in U.S. Pat. No. 5,794,164 to Beckert et al., which is incorporated herein by reference.
FIG. 1 shows a vehicle computer system 20. Vehicle computer system 20 has a centralized vehicle computer 22, like the Auto PC, operatively coupled to peripheral electronic systems and devices in an automobile. Essentially, the vehicle computer 22 is small computer that controls and monitors these peripheral components. It also provides functions that are traditionally associated with personal computers, such as an address database.
FIG. 1 shows peripheral components in the vehicle computer system 20. The components shown in FIG. 1 include a monitor 23, security sensors 25, a CD player 27, antenna(s) 29, speakers 31, a GPS receiver 33, an engine diagnostic component 35, other xe2x80x9cbuilt-inxe2x80x9d vehicle component(s) 37, and xe2x80x9cadd-onxe2x80x9d vehicle 11 component(s) 39. A xe2x80x9cbuilt-inxe2x80x9d component is one with its definition built into the operating system of the vehicle computer. An xe2x80x9cadd-onxe2x80x9d component is one that does not have its definition built into the operating system.
In general, a vehicle component is a part, device, or system that is capable of generating any vehicle-related data. In addition, a vehicle component is any part, device, or system that is capable of controlling any vehicle-related function. A vehicle component may also be called a peripheral or device.
Some additional examples of components include: switches, sensors, GPS receivers, MP3 players, DVD players, microphones, security systems, sound systems, navigational systems, wireless communications systems, vehicle diagnostic systems, microphone, multimedia systems, storage systems, climate control systems, batteries, and ignition systems.
FIG. 1 shows the computer 22 coupled directly to each component. Alternatively, one or more vehicle buses may connect multiple components to the computer 22 via vehicle gateways. A gateway is a hardware device that physically connects a component to an in-vehicle communications pathway (like an internal vehicle bus). For example, a vehicle may include a vehicle bus that provides the pathway for in-vehicle communications. A gateway provides a physical bridge attaching the component to that bus. Such a bus may be a USB. Such a component may be the vehicle diagnostics system and its Onboard Diagnostic Bus (ODB II). A gateway may be an ODB-USB hardware bridge.
The vehicle computer 22, like most computers, has an operating system and applications that execute there under. The applications can control or monitor the sound systems, security systems, vehicle diagnostic systems, global positioning system (GPS) navigational systems, wireless communications systems, and other systems. They may also provide an address database and provide a user interface.
The Auto PC uses a specially designed version of the xe2x80x9cWindows CExe2x80x9d operating system by the Microsoft Corporation. The xe2x80x9cWindows CExe2x80x9d operating system has a number of Application Program Interfaces (APIs) that are helpful to application program developers. These APIs are called by applications to perform a host of basic functions, so that the applications themselves need not implement such basic functions. Those who are skilled in the art are generally familiar with APIs and their use.
The following table shows examples of the APIs that the xe2x80x9cWindows CExe2x80x9d version for the Auto PC supports:
As shown in the above table, one of API sets is for the vehicle input/output (xe2x80x9cVehicle I/Oxe2x80x9d) system. The Vehicle I/O APIs (xe2x80x9cVIOAPIsxe2x80x9d) enable access to vehicle maintenance and diagnostic data and allows an application to control vehicle operations. VIOAPIs are a specific implementation of a generic set of
APIs called Device Communication Application Programming Interfaces (DCAPIs). Generally, DCAPIs are used by applications to communicate with peripheral vehicle components to monitor, collect, diagnose vehicle data and to control vehicle functions.
FIG. 2 shows the conventional communication techniques for an application on the vehicle computer 22 to communicate with components 74 and 76. An application 50 running on the vehicle computer may communicate with any component registered with operating system 52 of the computer. Operating system 52 includes APIs and their associated methods. More particularly, operating system 52 includes DCAPIs to facilitate communication between the application 50 and components.
The DCAPIs include interface methods to facilitate component communication and provide standard interfaces for the applications. The DCAPIs also provide access management and notification features. Herein, these methods are generically called xe2x80x9cdevice-communicationxe2x80x9d methods or xe2x80x9cdevice-comxe2x80x9d methods. The definitions of xe2x80x9cdevice-comxe2x80x9d interfaces and methods are drawn from the DCAPIs. Specific instances of device-com interfaces are shown at 54 and 56.
These interfaces and interface methods are defined and are implemented (at least in part) for each different type of peripheral component supported by the operating system. Specifically, in a system having a plurality of peripheral components and corresponding objects, each object has its own device-com methods that can be called by application programs. Although each of these device-com methods might communicate with a different type of component, the calling parameters of each device-com method are identical-the DCAPI of each object supports the same set of methods.
The following is a table of frequently used xe2x80x9cdevice-comxe2x80x9d methods of the Auto PC""s implementation of DCAPI:
Application 50 uses the xe2x80x9cdevice-comxe2x80x9d methods of the DCAPIs (represented by interfaces 54 and 56) to communicate though component objects 58 and 60. Although the specific implementation of the device-com methods of 54 and 56 are different (because the component objects are different), the device-com methods are drawn from the same definitions in the DCAPIs.
As shown in FIG. 2, communication between the objects 58 and 60 goes through intermediate software and hardware elements: mini-drivers 62, 66; device drivers 66, 68; and vehicle gateways 70, 72. These elements are standard Windows I/O elements, specifically tailored for a particular component. Components 74 and 76 are physically installed in a vehicle 80.
Mini-drivers 62, 64 are small component-specific objects that perform component-specific, low-level communication and data conversion. Mini-drivers are positioned between component objects and device drivers in the data flow path.
Device drivers 66, 68 are software that performs low-level communication functions so that transmissions can be sent/received over a specific physical medium and its communications protocol. Examples of such physical media and protocols are USB (Universal Serial Bus), RS-232, and proprietary in-vehicle buses. Device drivers are positioned between mini-drivers and vehicle gateways in the data flow path.
Vehicle gateways 70, 72 are hardware devices that physically connect components to the in-vehicle communications pathway, such as USB, RS-232, and proprietary in-vehicle buses. Gateways are positioned between device drivers and the components in the data flow path.
The application 50 could conceivably communicate with components 74, 76 directly through mini-drivers and device drivers and bypass the DCAPI and objects. However, this would require quite a detailed knowledge of the capabilities and protocols supported by each component. To reduce the burden placed on application programmers, components are represented by programming objects (such as 58 and 60). The objects have interfaces (DCAPIs) and interface methods (device-com) that can be called by the application to communicate with the components. The interfaces and methods hide the details of component communications from the application.
The Auto PC version of Windows CE integrally defines a number of different vehicle component objects, corresponding to different types of vehicle components. Such objects are referred to herein as xe2x80x9cbuilt-inxe2x80x9d objects because they are provided with the Auto-PC and/or its operating system. Each of the objects exposes the pre-defined DCAPI.
The architecture described thus far provides an easy way to support new components that do not have built-in object definitions in the Auto-PC. When designing a new component, the manufacturer also designs a new object. The object is designed to support the DCAPI. When the component is installed in a system, the new object (or its definition) is also installed on the vehicle computer. An application program can then invoke the methods of the DCAPI to access the functionality of the underlying component. Again, the application program does not have to be concerned with low-level communication details.
Component objects such as this, which are not designed as part of the operating system, are referred to herein as xe2x80x9cadd-onxe2x80x9d objects. The ability to use add-on objects is extremely beneficial. However, there remains one disadvantage to using add-on objects, relating to certain management functions provided for use in conjunction with the built-in objects. Specifically, the built-in components provide access control and notification capabilities. The add-on components are not able to provide access control and notification capabilities.
With reference to FIG. 2, the following describes the conventional communications between an application and a built-in component. The application 50 initiates communications with the built-in component 74 using the operating system 52. The application employs the standard xe2x80x9cdevice-comxe2x80x9d method 54 to communicate to the built-in component 74 through its object 58. An example of a xe2x80x9cdevice-comxe2x80x9d method typically used is an access management method called IVIO_Device::GetData (or simply xe2x80x9cget-dataxe2x80x9d).
Like its name implies, the get-data method is designed to request data from a component. The get-data method is called with two parameters. One is the address of a memory location that will hold the data in the response from the component. The other parameter is the amount of time to wait from a reply from the component. In addition to returning data, the component may indicate an error condition like: the component does not implement the requested data read, bad address, access denied, and unexpected error.
Built-in component object 58 does not include any low-level communication functionality to communicate with mini-driver 62. Rather, it relies on the functionality of the methods and interfaces of the DCAPIs. Via the DCAPIs, the object 58 communicates with mini-driver 62. The communication proceeds through mini-driver 62, device driver 66, and gateway 70. The built-in component 74 receives the communication. The component 74 will send a response along the same path back to the object 58. The object 58 and the device-com methods 54 will send the response back to the application 50.
If no error indicator was returned, the component will return the requested data. Presumably, the application will use this data for monitoring some condition of the component and/or the vehicle. For example, the component might measure the blackness and dirtiness of the vehicle""s oil. The application may use the measured values from this component to indicate whether the oil should be changed.
With reference to FIG. 2, the following describes the conventional communications between an application and an add-on component. The application 50 initiates communications with the add-on component 76 using the operating system 52. The application employs the standard xe2x80x9cdevice-comxe2x80x9d method 56 to communicate to the add-on component 76 through its object 60. The methods of interface 54 for the built-in object and the device-com methods of interface 56 for the add-on object are drawn from the same device-com definitions of the DCAPIs. Whether the component is built-in or add-on, the application sends and receives data using the same parameters and expecting the same results. An example of a xe2x80x9cdevice-comxe2x80x9d method typically used is an notification management method called IVIO_Device::SetNotify (or simply xe2x80x9cset-notifyxe2x80x9d).
The set-notify method is used by an application to instruct a component to send regular notification signals back to the application. The set-notify method is called with three parameters. One is the address of a memory location that will hold additional information about starting the notification. The second parameter is the address of the event sink. The third parameter indicates the frequency that the component should notify the application. The component may indicate an error condition like: the component does not implement the requested notification, bad address, access denied, and unexpected error.
Unlike the built-in object 58, the add-on object 60 includes its own low-level communication functions for communicating with the mini-driver. It does not employ the functionality of the DCAPIs. The add-on object 60 cannot use the object-minidriver-communication functionality of the standard DCAPIs because the add-on object is not integrally defined within the DCAPIs. This means that software developers must program all of the communication functionality into the add-on object 60.
On its own, the add-on object 60 communicates with mini-driver 64. The communication proceeds through mini-driver 64, device driver 68, and gateway 72. The add-on component 76 receives the communication. The component 76 will send a response along the same path back to the object 60. The object 60 and the device-com methods 56 will send the response back to the application 50.
If no error indicator was returned, the component will send notification signals to the event sink. The event sink is implemented by the DCAPIs and the application looks there to receive its notifications from the component.
It is possible for add-in components to implement the same access control and notification capabilities as the built-in components. However, this requires significant programming effort, which must then be repeated by each application programmer. Furthermore, without expensive and cumbersome specialized modifications, applications are unable to access and fully utilize the new add-on component.
The architecture described below addresses this deficiency in the conventional application-to-component communication techniques.
Described herein is a system for communicating with vehicle components such as described above. Each vehicle component has a corresponding object, and each object exposes a pre-defined Device Communication Application Programming Interface (DCAPI). Some objects are built-in, meaning that they are defined to some degree by the operating system, and rely on the operating system for at least parts of their functionality. Other objects are add-on objects, meaning that they are provided apart from the operating system, for subsequent installation and use in conjunction with the operating system.
The operating system provides a xe2x80x9cdevice helperxe2x80x9d that allows add-on components to participate and utilize access management and notification features provided by the operating system. The device helper exposes its method for use by corresponding device-com methods of component objects. The object calls the device helper method that corresponds to the called device-com method. This greatly simplifies the tasks of application programmers, and allows access management and notification services to be coordinated between the various component objects.